How Progress Dynamics handles a Web request
This section introduces you to the major Progress Dynamics components that are involved in processing a Web request and returning a DHTML page to a client browser.
The overall architecture is designed to maximize performance by reducing server hits. The DHTML page and data are sent separately, so only affected objects are updated, and slow updates of entire pages are avoided. Data caching is implemented on the client browser through JavaScript, so that updates can often be performed on the client side. In addition, updates for multiple SDOs are bundled on the client browser and sent to the server as a single request.
The following simplified illustration shows a round-trip request between the client browser and the Progress Dynamics Agent:
- The client browser initiates a request by means of a URL, as shown:
- The Web Server’s hostname.
- The path of the folder that contains the Progress Dynamics static files. The content of this folder includes HTML pages, Cascading Style Sheets, JavaScript files, and image files.
- The name of the startup Web page (usually
default.htm). - A name/value pair where the
icfobjvariable is set to the name of the Progress Dynamics application object. - The
default.htmfile causesryinithtml.jsto run, which initiates a WebSpeed request, as illustrated in the following diagram: - As in standard WebSpeed architecture, the Broker finds a free Agent and passes the request to it, as shown:
- The UI Manager extracts incoming data from the Web stream and sends it to the Session Manager to store in a context table in the Repository database, as shown:
- If a login is required at this point, the UI Manager sends a login page to the client. For Web browser applications, ICFWS session properties define login requirements. Use the Session Type Maintenance tool to modify ICFWS session properties. See the "ICFWS session" section.
- When login information is received, the Request Manager calls the Security Manager to authenticate the user. The Request Manager also calls the Session Manager to restore context, as shown:
- The UI Manager retrieves the application object information from the Repository Manager. The Web server accesses the static DHTML files (HTML layout, JavaScript, and Cascading Style Sheets) and images. Then the interface information is sent to the client, as shown:
- The UI Manager retrieves application data and sends it to the client, as shown:
- In the final stage, the UI Manager returns control to the Request Manager. The Request Manager does some flushing of context and other cleanup tasks. It is then available to handle another Web request.
Typically, the URL contains:
The format of the URL is:
The WebSpeed request includes the name of a Progress Dynamics Broker (in this case the default, wsdynamics1) and the name of the Progress Dynamics application object.
The standard WebSpeed Messenger/NameServer architecture is used to find the Progress Dynamics Broker.
Unlike the standard WebSpeed Agent, the Progress Dynamics Agent is comprised of Dynamics managers.
The Request Manager is the single point for all Web requests received by the Agent. On initially receiving a Web request, the Request Manager determines the client UI type and then accesses the appropriate User Interface (UI) Manager.
Although the Progress Dynamics Agent is running in the stateless mode, context can be maintained between requests because the Session Manager creates a unique ID for each session. This Session ID is passed back to the client. When the client sends another Web request, it includes a Session ID with the request. The Session Manager can match the Session ID with context tables and restore the context of the request. If there is no Session ID included with a Web request, the Session Manager creates a new one.
Note again that the Agent is not locked while waiting for the client to log in. When the client does log in, the login information (user name and password) also includes a Session ID so context can be restored.
Notice that the UI Manager sends interface information and application data as two separate steps in response to a single request. This provides a performance advantage for subsequent updates. Only data for affected objects will be sent. The need to update the entire page is eliminated.